Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000024_owner-urn-ietf _Wed Mar 12 11:40:19 1997.msg

Internet Message Format | 1997-04-01 | 10KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id LAA01583
    for urn-ietf-out; Wed, 12 Mar 1997 11:40:19 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id LAA01577
    for <[e-mail]>; Wed, 12 Mar 1997 11:40:14 -0500 (EST)
Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA22381  (mail destined for [e-mail]); Wed, 12 Mar 97 11:40:09 -0500
Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id KAA23966; Wed, 12 Mar 1997 10:40:00 -0600 (CST)
From: Daniel LaLiberte <[e-mail]>
Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id KAA08753; Wed, 12 Mar 1997 10:39:36 -0600 (CST)
Date: Wed, 12 Mar 1997 10:39:36 -0600 (CST)
Message-Id: <[e-mail]>
To: "Karen R. Sollins" <[e-mail]>
Cc: [e-mail]
Subject: Re: [URN] semantic representation in URNs
In-Reply-To: <v03010d02af4be31443f1@[18.26.0.235]>
References: <[e-mail]>
    <[e-mail]>
    <v03010d02af4be31443f1@[18.26.0.235]>
Sender: [e-mail]
Precedence: bulk
Reply-To: Daniel LaLiberte <[e-mail]>
Errors-To: "[e-mail]
 > At 4":01.PM.-0600.3/10/97,
        Daniel LaLiberte wrote:

Karen R. Sollins writes:
 > Location is one form of semantic information; think of it as one dimension
 > in semantic space.

Since the subject of this thread is semantics in URNs, and the broader
question is not just human friendly semantics but any kind of
semantics, we should probably try to stay at a level above the details
of particular semantic dimensions.  Each dimension could lead us off
in another direction.

For example, the issue of location semantics is a big one and is
exactly the same question as URNs vs URLs and whether they are
distinguishable.  Attempting to stay clear of that debate, it would
help if you could simply and precisely define location.  I.e. what are
(is?) the semantics of locations?  (Dan Connelly claims that there is
not a definition of location-independence in any RFC (or draft?))  My
claim is that any adequate definition of location would include URNs
themselves if URNs can be looked up in a globally consistent manner.
I'll respond to your definition in private mail.

So the general question, applied to other kinds of semantics, is: how
do you really know when you are building in some kind of semantics?
There is explicit semantics and implicit semantics.

But there are some other distinctions that should be considered in the
kinds of semantics.  There is semantics regarding the identifier
itself and semantics regarding the resource(s) associated with the
identifier.  For some kinds of semantics, it is difficult to
distinguish whether you have one or the other.  You give examples of
semantics of the resource:

 > Another might be programming language in which
 > something is implemented or natural language in which it is expressed.
 > Consider that another dimension. Another might be some indication of
 > underlying algorithm on which the resource is based.  Again, another
 > dimension.

But here are some semantics of the identifier itself.  The scheme name
(e.g. "urn:"), naming authority (single or hierarchy), structure of
the identifier itself are very low level semantics (i.e. on the
syntax-semantics continuum) about how to interpret the identifier
itself.  One step up from this, there might be a field that indicates
how to interpret the remainder of the identifier.  Others: there might
be a date field that indicates when the identifier itself was created,
not the resource it refers to.  There might be a checksum or signature
field that can be used to verify the identifier itself, not the
resource it refers to.

One place where the boundary between semantics of the identifier and
semantics of the resource gets blurry is in the organization of the
name space.  In a hierarchical name space with a hierarchical name,
the components of the name presummably (but not necessarily) map on to
the organization of the space.  This blurs the distinction because in
the process of resolving the identifier over several resolution steps,
you are getting closer to the resource itself.  As the organization of
the space changes, the concern is that the resolution process could
break.  I discussed strategies and mechanisms for dealing with that
reorganization in previous mail.

The key question regarding semantics is whether the semantics of the
organization of the name space is a reflection of the semantics of the
resources.  Yes and no.  Each node in the hierarchy (if it is a
hierarchy) can be considered to represent a collection, a resource
itself.  It may correspond to a resolution service that can provide
information about that collection resource.  But, importantly, these
collections need have no necessary semantic relevance in that the
resources in a collection need not be at all related to each other
other than being in the same collection.  Whether it is useful to have
no meaningful relationship between collection members is another
question.

What I think should happen is that these collections are meaningful,
but their meaning is not intended to be complete or persistent.  In
other words, the collection of /edu/uiuc/ncsa/liberte is generally my
stuff, but some of my stuff might also appear elsewhere
(e.g. /com/bunyip/ietf/urn/liberte) and I might provide access to
other people's stuff via my space (e.g. ../liberte/hotlist/urns).

Then we get down to semantics that is more clearly about the resource
itself, but notice that we are getting into the metadata question.
(I.e. What is the difference between data and metadata?)  Bunches of
metadata could be included in identifiers (e.g. title, author, date,
subject, etc), and some people consider this to be the true way to
name resources.  For small resources, the resource *itself* could be
in the identifier (e.g. Larry's "data" URI).

My argument is that there will always be semantics in identifiers
unless the identifiers are useless for anything except for being
meaningless identifiers.  The nature of semantics is an association
between things, so, for example, you can get from an identifier to
the associated resource.

[Philosophical tangent: The general principal I am applying is that
there are really continuums everywhere.  Wherever we draw lines, we
distinguish things that are not really distinguishable.  It seems
useful to draw lines anyway, but the Universe conspires to ultimately
erase them, or scribble over them.]

 > Of course the number of possibilities is unlimited.  Yes,
 > n-dimensional space.  If URNs can be assumed to contain semantic
 > information, services will be built on that assumption, taking advantage of
 > the embedded knowledge.

Given the argument (conclusion?) that there will always be semantics
in identifiers, the question is how much and what kind of semantics.
It is a trade off.  Generally, the more semantics a service takes
advantage of, the more it needs to be flexible when those semantics
may change.  Location semantics is a relatively simple case that
requires an indirection or sequence of indirections to eventually find
the resource at some location.

 > If that knowledge can become invalid just as
 > location information can become invalid, we have an n-dimensional problem
 > where in URLs we have a one-dimensional problem.

URLs can have just as many dimensions of semantics as URNs.

 > Seems undesirable to me,
 > but the question is whether we should actively discourage our "customers"
 > from shooting themselves in the foot in this particular way or not.

We should discourage people from building services that don't work in
the face of changing semantics.  Putting it that way let's people
decide for themselves whether and how they can deal with changing
semantics.

 > What I was trying to say is that if the hierarchy reflects delegation then
 > using it to reflect something else as well (say, for example, derivation)
 > is extremely difficult because it is overloading the meaning of
 > hierarchical components.  Doing this in general probably becomes impossible.

I would tend to agree that overloading hierarchical components with
other semantics could cause problems, but there are other places that
additional semantics could be included in an identifier.  For example,
semantics could be included before or after the hierarchial part
(e.g. the //higher-level-space/lower/level/space and
...;name=value;name=value extensions), or each component could have
its own additional semantics that applies only to itself, or maybe to
the remainder of the path.

 > Saltzer, J., Reed, D., and Clark, D.D., "End-to-End Arguments in System
 > Design", ACM Transactions on Computer Systems, Vol. 2, No. 4, November
 > 1984, pp. 277-288.
 >
 > This paper makes the argument that repeating functionality at different
 > layers of abstraction (particularly as exemplified in security mechanisms)
 > is a bad idea. It probably should be required reading for all systems and
 > protocol designers and implementers.  I strongly recommend it.

Looks very worthwhile.  1984 is BW (before web), so finding it on-line
might be difficult.  I'll have to take a trip to the library; could
be educational. :-)

 > ... And we say that semantics can be included in whatever language
 > the creator of the URN chooses, and if the semantics cannot be understood
 > and useful in other contexts, tough luck.

That's my conclusion too.

dan